Day25 把表單畫面做完了，按下「產生我的飲食建議」也能看到結果。但其實還沒有說明畫面為什麼拿得到後端的資料。這篇就來把這件事講清楚：前端跟後端到底是怎麼接起來的。

🧱 先看大方向：到底在接什麼？

可以把整個系統想成一間餐廳：

• 前端（使用者的瀏覽器）= 點餐的客人與菜單：負責讓客人填需求、看結果
• 後端（Lambda）= 廚房：負責真正的運算，還有去呼叫 AI（Bedrock）
• API = 服務生：把客人的點單送進廚房，再把做好的餐端回來

「串接 API」，就是讓前端這位客人，真的能透過服務生把需求送到廚房。在這之前，畫面上的數字是前端自己算的，沒有廚房參與。

❓ 為什麼一定要這樣做？

最大的理由只有一個：AI 的呼叫不能放在前端。

前端程式碼會被下載到每一位使用者的瀏覽器，任何人都看得到。呼叫 Bedrock 需要 AWS 的權限（Day12 的 IAM Role），這種權限如果放在使用者看得到的地方，等於把廚房鑰匙交給所有路人。所以必須由後端代替前端去呼叫 AI，前端只負責把需求送過去、把結果拿回來。

另外還有一個好處：營養數字是由後端的固定公式算的，不會因為使用者的瀏覽器不同而不一致。

🔧 這次做了哪些事（只挑最重要的）

1. 把「呼叫後端」包成一個函式

寫了一支 fetchNutritionPlan()，專門負責把表單資料送到後端、等回應。其他地方只要呼叫它，不用管 fetch() 的細節。

2. 畫面要知道「現在在等」：三種狀態

後端要花時間（尤其 AI 要想幾秒），所以畫面不能假裝沒事。我讓畫面記住三種狀態：

• idle（閒置）：還沒送出
• loading（等待中）：已送出，正在等結果。這時按鈕會顯示「產生中…」並且停用，避免使用者連按好幾次
• error（出錯了）：後端沒回應或失敗，要告訴使用者發生什麼事

3. 互動方式的改變：從「即時算」變成「按按鈕才算」

Day25 的表單是填完欄位就即時看到數字。接上 AI 之後這樣做不行了：

• 每次呼叫 AI 都要等幾秒
• 每次呼叫 AI 都要付費

如果還像以前一樣，使用者每打一個字就送一次，畫面會一直卡住，費用也會暴增。所以改成使用者填完、自己按下按鈕才送出。這是這篇最重要的設計判斷：「瞬間免費的運算」跟「需要等待又要付費的外部服務」，互動方式本來就該不一樣。

4. 踩到的坑：用 curl 測沒事，瀏覽器卻被擋

我先用 curl（命令列工具）測後端，一切正常。但換成真的在瀏覽器裡按按鈕，卻被擋下來，原因是瀏覽器有一道安全機制（CORS，Day11 有詳細說明）：網頁預設只能呼叫「同一個來源」，除非後端明確說「我允許」。curl 不是瀏覽器，不受這個限制，所以測不出來。

這給了我一個提醒：後端測試通過，不代表前端串接一定順利，中間還隔著瀏覽器這一關。

✅ 確認真的接上了

在真正的瀏覽器裡走了一次完整流程：填完表單、按下按鈕、確認四個結果面板都有出現。

小結

這篇的重點是三個想法：

1. AI 的呼叫要放在後端，因為前端的東西人人看得到
2. 畫面要誠實呈現「等待」，所以需要 idle、loading、error 三種狀態
3. 要付費、要等待的操作，改成讓使用者主動按下按鈕

前後端現在串起來了，但目前還是只有我自己的電腦看得到。下一篇 Day27 要把前端部署到雲端，拿到一個真正能分享給別人的公開網址。